Ethernet is increasingly popular as a transport network for high speed Wide Area Network (WAN) communications. Various techniques have been developed to enable the deployment of Ethernet transport networks with a mesh topology. Among other things, these enable the provisioning of topologically diverse paths for traffic protection, while preventing the formation of loops within the network.
Spanning Tree Protocol (STP) is frequently used to compute traffic forwarding paths through a mesh network, in such a manner that loops are prevented. Typically, each node will compute a spanning tree rooted at itself, and which extends to every other peer node in its network domain. For example, FIG. 1a illustrates an example in which an edge node (SA) 2 has computed a spanning tree 4 rooted at itself, and extending to all other edge nodes 6 in its “home” network domain 8. Once the tree 4 has been computed, a point-to-point (p2p) connection between the root node (SA) and any given peer edge node 6 (such as destination node, DA, shown in FIG. 1a) can be implemented by computing a path 10 through the tree, and installing appropriate forwarding state in each of the network nodes traversed 12 by that path 10.
In effect, STP converts the mesh network topology into a tree topology, so that packets are forced to traverse the network from any source address (SA) to any destination address (DA) by following the tree 4 rooted at SA. If a network failure (such as a node or link failure) occurs, the tree 4 must be re-computed to re-establish connectivity. In order to prevent network instability and formation of loops during the tree recomputation, all traffic through the tree 4 is terminated until the new tree has been computed, and forwarding state implementing the new tree installed in each node. In large mesh networks, this can require several seconds.
Faster recovery times can be obtained by localizing failures to a particular branch. With this arrangement, the branch of the tree that is directly affected by the detected failure is “pruned”, and a new branch recomputed, starting from the root of the pruned branch. This has an advantage in that only traffic to destination nodes lying “downstream” of the network failure is interrupted, while traffic is permitted to flow through the rest of the network tree. However, in this case, the failure recovery time is dependent on the location of the failure, and the topology of the tree, and so can be unpredictable.
Another approach is to compute two (or more) topologically diverse trees 4a, 4b rooted at SA, as shown in FIG. 1b. With this arrangement, each node is the “root” of a pair of trees, one of which can be designated as a working tree (shown in solid lines in FIG. 1b), and the other as a protection tree (shown in dashed lines in FIG. 1b). If a network failure affecting the working tree is detected, a failure indication message is propagated to the root node (SA), which can then “switch” traffic to the protection tree. In this case, the failure recovery time is principally dependent on the time required for the failure indication message to propagate to the root node, which can be relatively fast. However, this method requires the computation of a very large number of trees within the network, and it can be very difficult to guarantee topological diversity between the working and protection trees.
For Ethernet transport networks, it would be desirable to obtain failure recovery times comparable to those obtained in physical layer transport technologies such as Synchronous Optical Network/Synchronous Digital Hierarchy SONET/SDH, that is; 50 msec, or less. In theory, techniques based on the pre-computation of working and protection paths are capable of achieving this level of protection switching performance. However, this performance comes at a cost of great complexity. A simpler solution is desired.
ITU-T SG15/Q9 recommendation G.8032 (February, 2008) describes protection switching in an Ethernet ring. Referring to FIG. 2, an Ethernet ring 14 is an Ethernet network comprising nodes 16 and links 18 connected together in a ring topology. One of the links of the ring 14 is designated as a Ring Protection Link (RPL), and is disabled during normal operation of the ring by placing a channel block 20 on that link. Typically, a channel block 20 is imposed at a node at one end of the RPL. This node may then be referred to as the RPL Owner. In some cases, the channel block 20 may, for example, comprise a policy that prevents packets of the ring from being forwarded through a port hosting the RPL. With such a channel block in place, the ring 14 is guaranteed to be loop free, and conventional Ethernet MAC-learning and path computation can be used to compute forwarding state in each node 16 of the ring 14.
As described in ITU-T recommendation G.8032, a failure of either a link 18 or a node 16 of the ring 14 will be detected by the two nodes nearest the point of failure. Both of these nodes will install a channel block on the port facing the fault and will send a Failure Indication Message (FIM) to their adjacent nodes in the ring. These FIMs will be propagated, in opposite directions, around the ring. Upon receipt of the initial FIM, each node flushes its forwarding database (FDB), and forwards the FIM to the next node on the ring. In addition, the RPL-Owner will remove the channel block 20. This effectively enables connectivity within the ring to be re-established using conventional Ethernet flooding and MAC learning functionality. A convenient aspect of this approach is that the conventional Ethernet flooding behavior forwards traffic into the ring as the primary mechanism for MAC learning and path computation. As a result, traffic flow within the ring 14 is restored almost immediately after the FDB in each node 16 has been flushed, so that the failure recovery time of the ring 14 is dominated by the speed at with the FIMs propagate around the ring. Failure recovery times of 50 msec or less can readily be obtained in practical WANs. However, ITU/T recommendation G.8032 is based on a ring network topology. No comparable scheme is available for implementation in a mesh network.